Like any kind of apps, JavaScript apps also have to be written well.
Otherwise, we run into all kinds of issues later on.
In this article, we’ll look at some best practices we should follow when writing Node apps.
Use Arrow Function Expressions
Arrow functions are a great feature of modern JavaScript.
It lets us write callbacks without binding to a new value of this inside the callback.
Also, it’s more compact.
We should use to avoid bugs and have easier to read code.
Write API Tests
API tests let us check the results of our APIs.
We’ll know right away from the tests if we don’t get what we want.
They’re fast so we can test without lifting a finger.
Also, they’re great for documenting how to call our APIs.
There’re other kinds of tests like performance tests, database tests, etc. that we can do as well.
Include 3 Parts in Each Test Name
Our tests should be self explanatory.
So we should state in the test name what’s being tested.
Also, we should state what circumstances are being tested and what’s the expected result.
This way, no one will be confused with what we’re testing.
For instance, we can write:
describe('Item Service', () => {
describe('Add new item', () => {
it('When no price is specified, then the item status rejected', () => {
const item = new ItemService().add(...);
expect(item.status).to.equal('rejected');
});
});
});
We have the describes labeling what unit we’re testing.
And the string we pass into it has the scenario we’re testing.
The expect call and the it string have the expectation.
Detect Code Issues with a Linter
We can detect code issues with a linter so that we can detect antipatterns early.
To make this easy, we can add a pre-commit hook that runs before a commit is made to do the check.
Avoid Global Test Fixtures and Seeds and Add Data Per Test
Test fixtures should be added per test.
And the data should be scrubbed after each test.
This way, we won’t have tests that are dependent on each other.
With this done, every test should run in isolation so we can run them in any order.
Inspect for Vulnerable Dependencies
We should inspect for vulnerable dependencies so that we can update them.
This way, we can update them and avoid attackers attacking our app with those vulnerabilities.
To do this, we can run npm audit or other tools.
Tag Our Tests
We can tag our tests so that they run before a commit is made.
We run the ones that must be run to prevent committing any that breaks out code.
Otherwise, we’ll run all tests all the time, which is probably too slow for most apps before commit.
Check Test Coverage
Checking for test coverage lets us identify any decreases and check for things we missed in our tests.
Tools like Istanbul/nyc can check test coverage in our code so that we get a clear idea of what’s needed to be tested.
Conclusion
We should use arrow functions.
And we should have good test coverage in our code.
